quick navigator
Products
Technologies
Development Tools
* Common Data Security Architecture
* References & Resources
* Specifications

Developer Home Contents Search Feedback Support Intel(r)


Common Security Services Manager
Sample Applications
Cryptographic Service Provider Module
FAQ
General Questions
Common Security Services Mgr
CSSM Add-ins
Sample Security Applications
Integrity Services
Reference Implementation

General Questions

Q1: What is CDSA?
A1: CDSA is the Common Data Security Architecture. CDSA provides an open, cross-platform, interoperable, and extensible software framework consisting of APIs designed to make computer platforms more secure for applications such as electronic commerce, communications, and digital content.

 

Q2: What role did Intel play in developing CDSA?
A2: Intel Architecture Labs developed specifications for CDSA and then worked with our collaborators like IBM and Netscape to further refine it within The Open Group standards process.

 

Q3: Why does the world need PC security architecture from Intel – aren’t there good solutions in place now?
A3: Today, many security solutions exist for different aspects of the security problem. Every independent software vendor (ISV) has to deal with integrating security features into their applications. Often, ISVs design solutions that do not interoperate with applications from other ISVs. CDSA unifies multiple security approaches and when used as directed will provide interoperability between different applications that build security.

There are a variety of cryptography and security related standards currently in the market. CDSA provides a common specification for managing the various security related services embodied in these and other security standards.

 

Q4: How will CDSA relate to and work with existing security standards?
A4: CDSA does not replace any existing standards for data formats or communication protocols related to security, nor does it establish a new standard in any one security service area. Instead, it provides a management infrastructure for various security related services and defines an API through which applications access those services.

 

Q5: What does it mean to make the PC more secure?
A5: There are four basic elements of security: privacy, integrity, authenticity, and non-repudiation.

Privacy: Information is scrambled in such a way that when viewed it cannot be understood except by the intended reader.

Integrity: Data is transmitted or stored in a tamperproof manner. If the data is modified, or if forged data is introduced, those alterations are readily detected.

Authenticity: The identity of the user responsible for the data creation can be verified.

Non-repudiation : The users that created or sent the data can not falsely deny that they are responsible for it.

 

Q6: What problems does CDSA solve?
A6: CDSA makes the process of adding security to software products easier. By writing to one common API, a software developer can add authentication services (such as smart card readers), encryption services (such as DES) and the ability to manage security processes (key recovery, export restrictions, prevention of attacks on the internal software pieces). Application developers can focus on a single API for all security services, and not individual API sets for each security offering from multiple toolkit vendors. This provides application developers with flexibility, consistency, and portability when implementing security solutions within their products.

 

Q7: What are the current problems with security on PCs?
A7: The strength of the PC, a flexible and open architecture, makes it particularly susceptible to attack from "digital bandits". Although the PC is an optimal device to access the Internet, it is subject to threat from multiple people 24 hours a day. Both perception and reality of security risks are preventing people from using the PC for sensitive transactions, such as e-commerce. Hardware and software developers build minimal security into their products today. It appears to be more efficient for them to integrate existing security components from third party developers rather than develop the technology themselves.

 

Q8: What is the current status of CDSA?
A8: A reference implementation of V1.2 of CDSA for Windows 95/ NT is available from Intel. A V2.0 specification has been adopted as a standard by The Open Group - a standards organization consisting of over 200 member companies that was formed after the merger of OSF and X/Open. We believe this specification will help the industry to ensure that application developers can abstract security away for their applications and have it provided by pluggable security service providers that are interchangeable.

 

Q9: Does CDSA compete with existing solutions from security vendors?
A9: CDSA does not compete with existing solutions on the market today. CDSA does not directly provide any security services. CDSA is a framework that allows any security vendor to write add-in modules that will work in the CDSA environment. These add-in modules would be available to any application that uses the CDSA for its security capabilities. The CDSA specification provides a set of service provider interfaces (SPIs) for add-in vendors. If a security vendor writes an add-in module conforming to this SPI, it will be available to CDSA applications.

 


Common Security Services Manager

Q10: What is the Common Security Services Manager (CSSM)?
A10: The Common Security Services Manager is an extensible infrastructure that defines a certificate-based API for security services, and manages add-in security modules that provide services to applications, in accordance with the CSSM-defined API.

 

Q11: How is CDSA different from CSSM?
A11: The CDSA model defines several layers. The Common Security Services Manager (CSSM) is one layer of the model that provides management of the security infrastructure through a series of API function calls. The APIs associated with this layer will be consistent across multiple platforms, providing flexibility to applications requiring security.

 

Q12: Is the CSSM susceptible to security attacks?
A12: In order to provide security, CSSM must also protect itself from compromise. CSSM uses signed manifests as credentials for providing self-checks, and checking add-ins. The Embedded Integrity Services Library (EISL), and the Integrity Services Library (ISL) are used to verify and to create these credentials. These libraries provide self integrity checks, bilateral authentication of modules, and other integrity services.

 

Q13: Can I run multiple applications concurrently using CSSM?
A13: Yes. In the current release of CSSM each application will execute its own copy of CSSM.

 

Q14: I received a notification that my copy of the Common Security Services Manager will expire in a few days. Why?
A14: Consistent with other software programs, the expiration date of this software helps to ensure that participants are using only the most current versions of the software.

 

Q15: Is a system running with an Intel PentiumŪ processor required to run the Common Security Services Manager?
A15. We recommend using a system running with an Intel PentiumŪ processor.

 

Q16: How can I find the current version number of the CSSM that is running on my system?
A16: Programmatically, the CSSM version number is returned by the function CSSM_GetInfo( ).

 

Q17: After uninstalling the CSSM, CSSM-related entries remained in the Windows registry. How can these be removed?
A17: The uninstall process should not leave any residual entries in the Windows registry. If you observe this problem, please send mail to IAL_Support@intel.com or call 1-800-628-8686.

 


CSSM Add-ins

Q18: What is a Cryptographic Service Provider (CSP)?
A18: A CSP provides encryption capabilities for the system. CSP’s can be either hardware-based (PC add-in card, smart card, etc.), software-based, or a combination of both. A CSP typically provides the following functions:

  • Data Encryption
  • Data Decryption
  • Digital Signatures
  • Cryptographic Hashing
  • Key Generation
  • Random Number Generation
  • Secure persistent storage of private keys

 

Q19: Can I use previous cryptographic systems with CDSA?
A19: In order to support legacy CSPs, vendors can use an adaptation layer that sits between CSSM and the legacy CSP. This adaptation layer maps the CSSM service provider interface (SPI) for cryptographic services into the legacy API of the CSP. In the future, CSP providers will native CSPs which support the CSSM API directly without the need for an adaptation layer.

 

Q20: Does Intel provide any CSPs?
A20: Currently, Intel provides one software CSP with its reference implementation of CDSA V1.2.

 

Q21: I received a notification that my copy of the CSP has expired. Why?
A21: Consistent with other software programs, the expiration date of this software helps to ensure that participants are using only the most current versions of the software.

 

Q22: Is a system running with an Intel PentiumŪ processor required to run my copy of the CSP?
A22. We recommend using a system running with an Intel PentiumŪ processor, 90 MHz or greater.

 

Q23: What cryptographic algorithms are supported in this CSP add-in?
A23: The Intel cryptographic add-in security module supports the following cryptographic algorithms:

  • Digital Encryption Standard (DES) - performs bulk encryption (key length is limited to 40 bits)
  • Secure Hash Algorithm (SHA1) - generates one-way data hashes
  • Digital Signature Standard (DSS) - performs digital signature creation, signature verification, and key-pair generation
  • Message Digest (MD5) - generates one-way data hashes
  • Random Number Generator - uses MD5/DES algorithms

 

Q24: What tools are provided to create a CDSA-compliant CSP plug-in?
A24: Intel provides a developer toolkit to help CSP add-in vendors move legacy CSPs to the CDSA environment. This toolkit is called the token adaptation layer (TAL). Intel used the TAL to develop Intel’s native software CSP, and two adaptation layers for legacy CSP-API (RSA’s BSAFE and PKCS#11). The TAL provides a framework that vendors can use to quickly develop CDSA-compliant CSPs.

 

Q25: What is a Certificate Library?
A25: A certificate library module performs operations on digital certificates. Each certificate library has knowledge of one or more specific certificate formats. Some of the operations performed by a certificate library include:

  • Creation, registration, and recovery of certificates from a Certificate Authority
  • Signing and signature verification of certificates
  • Management of certificate fields
  • Export and import of multiple certificate formats

 

Q26: Does CDSA mandate any certificate formats for a certificate library?
A26: Certificate format is defined by the add-in vendor module and not by CDSA. A certificate library vendor can support any format, including X.509, SDSI, or SPKI, for example.

 

Q27: Does Intel provide any certificate libraries?
A27: Intel developed a basic reference implementation of a certificate library supporting X.509v3 certificates and X.509v2 certificate revocation lists (CRLs). The purpose of the module is to provide add-in vendors with an example of a complete certificate library. Portions of this library are Windows* Operating System specific.

 

Q28: What is a trust policy?
A28: A trust policy is a set of rules used to determine if a requester is trusted or authorized to perform an action on a data object. Typical actions that might require trust verification by a trust policy module are:

  • Signing of certificates and certificate revocation lists
  • Verifying certificates and certificate revocation lists
  • Revoking certificates
  • Some application specific action or operation

 

Q29: Does Intel provide any trust policy modules with CDSA?
A29: Intel developed a basic reference implementation of a trust policy module. Trust policy definition is specific to an application domain. The purpose of the reference implementation is to provide add-in vendors with an example and starting point for developing a trust policy add-in module specific to an application domain.

 

Q30: What is a data service library module (DLM)?
A30: The data service library module provides persistent storage for security related objects used throughout the CDSA product. In particular, these objects could be certificates, certificate revocation lists, public keys, or trust information. A DLM can use a commercial database package, custom hardware, or native file system as the underlying mechanism to store these persistent objects. In particular, a DLM provides the following services:

  • Management of data stores, including creation, deletion, and import/export of data stores
  • Storage and management of security objects
  • Management of attributes associated with stored security objects

 

Q31: Does the DLM store items in a secure manner?
A31: The definition of the DLM does not require that the stored data be private, authenticated, or integrity checked. A particular DLM can choose to include any of these features as part of its service. This has no effect on the API’s for the DLM.

 

Q32: Does Intel provide a DLM module with CDSA?
A32: Intel developed a basic reference implementation of a DLM.The purpose of the module is to provide add-in vendors with an example and starting point for DLM add-in module development. The reference DLM does not explicitly store data in a secure, or encrypted format. For any sensitive information, the data should be secured before being stored by the DLM. Parts of this implementation are Windows* operating system specific.

 

Q33: Can I create my own trust policy add-in security module? Or certificate library module? Or data storage library module? Or cryptographic service module?
A33: Yes. The interface that must be supported by an add-in security module is documented in a corresponding service provider specification:

 


Sample Security Applications

Q34: What sample applications are provided by Intel?
A34: Intel currently provides four sample applications For download : Certificate Manager, Certificate Viewer, KeyKeeper, and Electronic Shrink Wrapper (ESW). For more information concerning these application go to the Sample Security Application page.

 

Q35: Can I create my own applications using the CSSM and add-in security modules?
A35: Yes. Using the security APIs documented in the Common Security Services Manager API Specification you can implement new, secure applications or augment existing applications with security facilities.

 


Integrity Services

Q36: What is EISL?
A36: The Embedded Integrity Services Library (EISL) is a statically linked library that can be used within CDSA software modules to provide self integrity checks and bilateral authentication.

 

Q37: Why do I need to check for integrity?
A37: Performing integrity checks for CSSM and add-in makes it difficult for an attack to modify the system without being detected. By providing self check capabilities, each software module can make sure that its code has not been tampered with, either maliciously or by accident.

Bilateral authentication ensures that software modules that use services from each other are authentic and their integrity has not been compromised. CSSM will check the integrity of add-in modules to ensure that a malicious or corrupted module is not added to the system. In addition, an add-in module can use EISL to check the CSSM, to make sure it is not being loaded by a malicious or corrupted CSSM.

 

Q38: What does ISL provide?
A38: The Integrity Services Library (ISL) is a superset of EISL. In addition to providing self integrity checks and bilateral authentication, the ISL uses CSSM to sign objects. ISL also signs and verifies objects other than the software code objects manipulated by EISL. Examples include objects referenced by URL and arbitrary data streams such as video, audio, etc.

 

Q39: What are the differences between EISL and ISL?
A39: EISL is embedded into the CSSM module, or add-in module, in order to enforce integrity between modules used within CDSA. EISL uses pre-defined cryptographic hashing and verification algorithms, as well as certificates and signed manifests, and is not extensible.

ISL can provide similar services to EISL, but is allowed to use add-in modules from CDSA in order to manage the certificate, trust, and cryptographic service routines required to provide integrity. This allows ISL to perform a broader range of security services.

 

Q40: What algorithms does EISL use?
A40: EISL uses the following algorithms/formats for module self checks:

  • Credentials : X509.V3 certificates for identification and signed manifests
  • Digests : SHA-1
  • Signature Algorithm : DSA
  • Signature Format : PKCS#7

 

Q41: What is a signed manifest?
A41: A signed manifest aggregates integrity and authentication information for a list of digital objects and is signed using public key technology. A manifest is extensible, so that additional arbitrary attributes can be added to any digital object within the manifest. Each module that requires a self integrity check, or participates in bilateral authentication, will provide a signed manifest. CSSM requires that a module’s associated manifest be stored in the file system with the module's executable object code, where it can be located and verified during bilateral authentication.

Q42: Where can I find out more about EISL/ISL?
A42: The following documents contain more information about integrity services:

  • CSSM Embedded Services Integrity Library API
  • CDSA Signed Manifest

 


Reference Implementation

Q43: What is currently available from Intel?
A43: Intel provides a demo reference implementation of CDSA V1.2 to qualified individuals. The reference implementation version of CDSA contains the following:

CSSM/Add-ins:

  • Binary to CSSM Core
  • Binary to Intel add-ins : Certificate Library (CL), Data Storage Library (DL), Trust Policy (TP), and weak non-RSA Cryptographic Service Provide (CSP) modules.
  • Binary to Integrity Services Library (ISL) and Embedded Integrity Services Library (EISL)
  • Install Program
  • Readme and release notes files
  • Sample database (DSA-based for web)

Sample applications:

  • Binary to the following CDSA applications: Certificate Viewer, Certificate Manager, KeyKeeper, ESW
  • Source code to Certificate Viewer, Certificate Manager, and KeyKeyper
  • Build environment for the above applications
  • Application Notes, ESW Notes

To find out more about qualifying for the demo reference implementation, send email to cdsa@ibeam.intel.com. Include your name, company name, mailing address and phone number. The demo software is available only in the United States and Canada.

 

Q44: When will the Common Security Services Manager version 1.2 expire? When will the next version be available?
A44: The Common Security Services Manager version 1.2 expires on  Sunday, September 30, 1998. To continue using the CSSM you must download a new copy from Intel’s corporate web site. A date for the next version of CSSM has not been determined.

 

Q45: Is special hardware required to run the Common Security Services Manager, or any of the related downloadable software?
A45: Special hardware is NOT required to run the Common Security Services Manager, the Cryptographic Token, or the sample security applications. For best performance, we recommend a system with an Intel PentiumŪ processor (90 MHz or greater). The system should have a minimum 8 MB of RAM; 16 MB is recommended.

 

Q46: Does the Common Security Services Manager require any other special software or system configuration?
A46: The requirements for the CDSA reference implementation are as follows:

Operating System
Windows* 95, Windows NT* 4.0
Database
To run the sample applications, you will need ODBC drivers for Microsoft Access* 7.0, (version 3.50.00.00 or greater).
 

Q47: What database does the Intel reference implementation use for local certificate storage?
A47: The Intel reference implementation uses ODBC drivers for Microsoft Access* 7.0. Support for other databases would have to be provided by other Data Storage Library add-ins.

 

Q48: When will the Common Security Services Manager run on other operating systems, such as Windows 3.1 and UNIX*?
A48: The CSSM API specification is intended to be platform independent. A source and release date for a CSSM reference implementation on other platforms has not been determined.

 

Q49: What release notes are available and how do I obtain them?
A49: Release notes for the Intel CSSM and Intel Add-ins are in a document titled relnotes.doc, and the readme file   for the software download is included in the document titled readme.txt.

 


Please send general comments and questions to cdsa@ibeam.intel.com

To top of page
* Legal Information © 1998 Intel Corporation